A file server is a type of storage server which operates on behalf of one or more clients to store and manage shared files in a set of mass storage devices, such as magnetic or optical storage-based disks. The disks in a file server system are typically organized as one or more groups of Redundant Array of Independent (or Inexpensive) Disks (RAID). One configuration in which file servers can be used is a network attached storage (NAS) configuration. In a NAS configuration, a file server can be implemented in the form of an appliance that attaches to a network, such as a local area network (LAN) or a corporate intranet. An example of such an appliance is any of the NetApp Filer products made by Network Appliance, Inc. in Sunnyvale, Calif.
A file server implements a file system, which is a software layer that keeps track of the stored data in response to storage operations, i.e., read and write operations. In a large system, it may be impractical to save data modifications to disk every time a write request is received from a client. Therefore, the system may instead save modifications to disk periodically, such as every 10 seconds, depending on the requirements of the system. Modifications are saved to disk during an event called a “consistency point”. In this approach, there is an inherent risk, albeit small risk, of losing data modified since the last consistency point if a failure occurs between consistency points. The risk increases as the amount of time between consistency point increases. Consequently, certain file servers such as the NetApp Filer products maintain, in a nonvolatile memory, a log of write requests received from clients since the last consistency point. This log is referred to as the “NVLog”.
Maintaining the NVLog provides considerable protection against loss of data in the event of a system failure between consistency points. However, whenever data is transferred or stored within a processing system, there is a possibility the data can be corrupted, particularly if a failure has occurred. Therefore, to provide further protection against loss of data, it is desirable to have a way of verifying the integrity of data in the NVLog.
One known way of verifying NVLog data integrity is to include a checksum in the NVLog. FIG. 1 illustrates an NVLog in accordance with this technique. The NVLog 1 includes a log header 2 followed by a number (N) of entries 3, each entry representing a separate write request from a client. The log header 2 includes several information entities, including an Entry Count 4, a checksum 5, a CP (consistency point) count 6, and other metadata 7. The Entry Count 4 indicates the number of valid entries currently in the NVLog. The CP count identifies the last consistency point to be completed. Each request 3 includes an entry header 8 followed by a data field 9 containing the data associated with the request (if any), e.g., the data to be written to storage. The checksum 5 in the log header 2 is used to verify data integrity of the entire NVLog 1.
While this approach provides considerable added protection against loss of data, it is not an ideal solution. For example, the checksum 1 might be a function of all of the times at which the requests 3 were received by the file server (e.g., an XOR function). Yet if all of the requests 3 were received during the same smallest interval of time measured by the file server, the checksum will be weak. Moreover, with this approach there is an inherent trade-off between the strength of the checksum and system performance: the stronger the checksum is, the more computationally expensive it is, i.e., the slower execution tends to be. The above-described approach provides little flexibility regarding the use of system resources. What is needed, therefore, is an improved way of verifying NVLog data integrity, which can provide stronger data protection as well as greater flexibility.